Subject: HPR/ATM Support for ATM Forum UNI 3.0

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Tue, 23 Jan 96 14:31:22 EST

Prior to AIW9, Steve Berl (Cisco) requested that the HPR/ATM document
support ATM Forum UNI 3.0 as well as UNI 3.1.  At AIW9, the HPR SIG
decided to postpone a decision pending further investigation on whether
ATM switch vendors and carriers would support mapping between 3.0 and
3.1.  The concern was that HPR nodes supporting 3.0 would not be able to
communicate with HPR nodes supporting 3.1.  I have done some
investigation of this issue and would like to report my findings.

The major difference between UNI 3.0 and 3.1 is that their signaling
protocols between an ATM switch and an attaching endstation are
incompatible.  As a result, a 3.0 endstation can only attach to a
3.0 port on a switch, and a 3.1 endstation can only attach to 3.1 port.
However, the differences between the actual information elements (IEs)
used in 3.0 and 3.1 signaling are minor for data applications like HPR
that use AAL Type 5.  The differences are attached at the end of this
note.

These differences can be overcome with mapping in the ATM network; an ATM
switch would modify 3.0 IEs received across the network before passing
them to an attached 3.1 endstation and vice-versa.  Rao Cherukuri advises
that we should not expect 3.0/3.1 mapping to be a widely-available
function on ATM switches (I have learned that the IBM 8260 and the
StrataCom IGX product provide 3.0/3.1 mapping.)  However, communication
between UNI 3.0 and UNI 3.1 endstations will usually be possible without
mapping provided the endstations and switches are tolerant to the
differences between the IEs of UNI 3.0 and UNI 3.1.  If either
endstations or switches are intolerant to the differences, the likely
consequence is that some calls will be unsuccessful.

By the time HPR/ATM ships, we expect that 3.1 offerings will be generally
available, but there are scenarios where customers would like the
flexibility to use 3.0.  For example, a customer might have made an
investment in 3.0 equipment, or his carrier might be slow in offering 3.1
service.  In addition, some ATM vendors might jump from UNI 3.0 to
UNI 4.0.

Other groups have already decided to support UNI 3.0.  RFC 1755, ATM
Signaling Support for IP over ATM, supports both UNI 3.0 and UNI 3.1
(Appendix B of RFC 1755 provides implementation notes for UNI 3.0
support); if HPR were to support only UNI 3.1, HPR could be at a
disadvantage to IP.  Likewise, the ATM Forum LAN emulation specification
supports both UNI 3.0 and UNI 3.1 implementations.

As noted above, the differences between the UNI 3.0 and UNI 3.1 IEs are
minor.  Therefore, provided that an HPR product has ATM adapters that
can support either UNI 3.0 or 3.1, the effort required for that product
to support HPR over both UNIs should be small.  As a result, I believe
that the benefits of supporting UNI 3.0 outweigh the costs and risks and
that the HPR SIG should make UNI 3.0 support a product option.

Gary Dudley
IBM APPN Architecture Team
------------------------------------------------------------------------
   1. ATM Adaptation Layer Parameters IE

      UNI 3.0 allows values for the forward maximum CPCS-SDU size and the
      backward maximum CPCS-SDU size to range between 1 and 65,535, but
      UNI 3.1 also allows a value of 0.  A 0 value indicates there will
      be no data flowing in that direction on the SVC.

      UNI 3.0 also defines an optional Mode field that is not defined for
      UNI 3.1.

   2. ATM Traffic Descriptor IE

      For UNI 3.0, this IE was called ATM User Cell Rate.

      For UNI 3.0, the specified traffic parameters relate only to user
      traffic: however, for UNI 3.1 the parameters relate both to user
      traffic and end-to-end F5 OAM cells which are policed together.

   3. Broadband High Layer Information IE

      For UNI 3.0, the High Layer Information Type field has a setting
      for high layer profile.  This setting is not supported by UNI 3.1.

   4. Called Party Subaddress and Calling Party Subaddress IEs

      The setting of ATM endsystem address for the Type of Subaddress
      field is not supported by UNI 3.0.

   5. Cause IE

      There are several differences in the UNI 3.0 and UNI 3.1 encodings
      for the Cause Value field.  There are, however, no overlaps in the
      encodings.

      UNI 3.1 reassigned the encodings for 2 values of the field.
      User cell rate not available is encoded as 37 instead of 51;
      AAL parameters cannot be supported is encoded as 78 instead of 93.

      UNI 3.1 added two values; VPCI/VCI assignment failure is
      encoded as 36, and normal call clearing as 16.

      UNI 3.1 does not support the UNI 3.0 value VPCI/VCI unacceptable
      that is encoded as 10 in UNI 3.0.

   6. Quality of Service Parameter IE

      For UNI 3.1, a new setting of ITU-T standardized is defined for the
      Coding Standard field.

      UNI 3.1 also defines a new setting for both QoS class fields that
      is reserved by ITU-T for indication of parameterized QoS.